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Description 

Background 

This invention relates to accessing information in a 
database. 

A database is a body of information that is logically 
organized so that it can be stored, searched and re- 
trieved in a coherent manner by a "database engine" -- 
a collection of software methods for manipulating data 
in the database. The software methods typically are im- 
plemented as a set of callable routines, either functions, 
which return a value, or procedures, which do not return 
a value. 

Databases generally fall into three categories: rela- 
tional databases, object-oriented databases and object- 
relational databases. A relational database (RDB) is a 
collection of fixed-field two-dimensional tables that can 
be related (or "joined") to each other in virtually any man- 
ner a database developer chooses. The structure of a 
relational database can be modified by selectively rede- 
fining the relationships between the tables. A database 
engine may perform complex -searches on a relational 
database quickly and easily by using any of various da- 
tabase query protocols such as the method expressed 
by the Structured Query Language (SQL) or by other 
mechanisms. The relationships between the tables en- 
able results of a search to be automatically cross-refer- 
enced to corresponding information in other tables in the 
database. 

As shown in Fig. 1 , for example, a relational data- 
base 100 includes a customer table 102 which is joined 
by a logical link 103 to an order table 104 which in turn 
is joined by a logical link 105 to an inventory table 106. 
A user may query the database 100, for example, for all 
order numbers higher than a threshold value. Because 
the order table 1 04 is joined with the customer table 1 02 
and the inventory table 1 06, a list of order numbers iden- 
tified in response to the query can be retrieved and dis- 
played along with the respective customer names and 
inventory items that correspond to the identified order 
numbers. 

An object-oriented database (OODB) is a collection 
of "objects" - software elements that contain both data 
and methods for manipulating that data. In contrast to a 
relational database which can store only numeric or 
character-type data, an OODB can store data of virtually 
any type (text, 3D graphic images, video clips, etc.). An 
OODB stores its constituent objects in a hierarchy of 
classes with associated methods so that the OODB con- 
tains much of the logic it needs to do useful work. A re- 
lational database in contrast contains only data and 
must rely on external application software to perform 
useful functions with the data. 

An object-relational database (ORDB) is a hybrid of 
the other two types. Extended data (e.g., a movie file) 
may be stored and retrieved in an ORDB either as part 
of a row or as a binary large object (BLOB) -- an undif- 



ferentiated mass of data. An ORDB also can access 
methods (e.g., a utility for viewing movie files) for ma- 
nipulating the data contained within a BLOB. These 
methods may be maintained separately from the data- 
5 base engine or may be linked to it depending on the par- 
ticular ORDB implementation. 

In an extensible object -relational database man- 
agement system (ORDBMS) such as the Informix® Uni- 
versal Server (IUS®), methods for manipulating extend- 
io ed data are linked directly to the database engine so 
that the extended data is treated as a "native" data type 
-- that is, a data type that the ORDBMS itself can ma- 
nipulate without resorting to external applications. In . 
Fig. 2, for example, an extensible ORDBMS 200 has ex- 
's tensions X and Y, which respectively contain methods 
for manipulating data types X and Y, linked directly to 
the database engine 202. In response to a database 
query that points to data of type X, for example, the da- 
tabase engine 202 automatically invokes the methods 
20 jn extension X to manipulate the data in an appropriate 
daita type-specific manner. 

A non-extensible ORDBMS, in contrast, does not 
allow data manipulation methods for arbitrary data types 
to be linked to the database engine but rather requires 
25 the use of multiple data type-specific engines, intercon- 
nected via layers of middleware, to manage multiple da- 
ta types. As a result, a non-extensible ORDBMS gener- 
ally exhibits reduced performance and presents a de- 
veloper with increased complexity in deploying new ap- 
30 plications. 

Summary 

In one aspect of the invention, routines for manipu- 
35 lating data in a database are performed by a database 
server by determining whether or not a database ma- 
nipulation routine is to be isolated from a specified range 
of memory, and, in response, selectively switching 
memory access permission to the specified range of 
40 memory (e.g., from read/write to read-only) for the da- 
tabase manipulation routine under consideration. The 
database manipulation routine is then executed using 
the selectively switched memory access permission. A 
database manipulation routine that is to be isolated can " 
45 be executed with readonly memory access thereby pro- 
tecting the specified range of memory from improper 
modification. 

Whether or not a database manipulation routine is 
to be isolated from a specified range of memory (e.g., 

50 core memory in which core data structures reside) may 
be determined by inspecting a parameter associated 
with the database manipulation routine. The parameter 
can be set to value that specifies a class of processor 
(e.g., a multi-threaded virtual processor) for executing 

$5 the database manipulation routine. A certain class value 
indicates that the corresponding processor should be 
isolated from core memory by restricting the processor's 
core memory permissions to read-only. Other class val- 
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ues can indicate that the corresponding processor need 
not be isolated from core memory and thus may have 
full R/W permission to core memory. 

Selective switching of memory access permissions 
may be accomplished through a local procedure call 
which sets the memory access permission for the data- 
base manipulation routine to read-only for core memory 
if the database manipulation routine is determined to be 
"untrusted" i.e., a routine that is to be isolated from 
core memory. Alternatively, the memory access permis- 
sion for the database manipulation routine may be set 
to read/write for core memory if the database manipu- 
lation routine is determined to be a "trusted" routine -- i. 
e., a routine that need hot be isolated from core memory. 

When an untrusted routine is to be executed, a local 
procedure call causes the thread of execution for the 
database manipulation routine to migrate from a proc- 
essor that has read/write permission to core memory to 
a processor that has read-only access to core memory. 
The thread migrates to a memory region that is logically 
partitioned from core memory but which is in the same 
memory address space as core memory. The thread is 
in "a trusted context" when it has read/write permission 
to the core memory and in "an untrusted context" when 
the thread has read-only access to core memory. 

When executing in an untrusted context, the thread 
nevertheless may need to use a resource in the core 
memory to execute the database manipulation routine. 
Upon detecting that condition, a switch from the untrust- 
ed context to another trusted context is performed to al- 
low, for example, the thread to modify core memory. Af- 
ter the thread has completed the use of the resource in 
core memory, a switch is performed from the trusted 
context back to the untrusted context. Similarly, after the 
untrusted routine has completed execution, a switch is 
performed from the untrusted context back to the origi- 
nal trusted context. Any arbitrary number of switches 
may be performed between a trusted context and an un- 
trusted context. 

In performing a context switch from an untrusted 
context to a trusted context, entry into core memory may 
be limited to a predetermined set of one or more per- 
missible execution entry points, for example, identified 
in a predetermined call back table. If a specified entry 
point appears in the call back table, entry at that point 
in core memory is allowed. If, however, a specified entry 
point does not appear in the call back table, entry at that 
point in core memory is blocked. 

In another aspect of the invention, routines for ma- 
nipulating data in a database are performed by a data- 
base server by dividing a memory address space into 
memory segments (e.g., a main segment and one or 
more fenced segments). A database manipulation rou- 
tine, for example, an untrusted user-defined routine, se- 
lectively may be executed in a fenced memory segment 
while preventing the routine from writing information to 
another of the memory segments. The database manip- 
ulation routine executing in the fenced memory segment 



can be enabled to read information from another mem- 
ory segment or to migrate to another memory segment 
to perform a predetermined routine. Other routines, for 
example, trusted core database routines can be execut- 
ed in the main segment with full R/W access to all mem- 
ory segments. In addition, multiple database manipula- 
tion routines may be executed in respective ones of the 
memory segments, each database manipulation routine 
having read-only access to all memory segments other 
than its own memory segment. 

Advantages of this invention may include one or 
more of the following. Allowing users to define their own 
routines and to link those user-defined routines to the 
database engine enables the database server to man- 
age an arbitrary collection of rich data types (e.g., im- 
ages, video, sound, maps, complex financial instru- 
ments, time series data) quickly and efficiently. Any risk 
that a user-defined routine containing faulty logic will 
corrupt the database is minimized because such user- 
defined routines are isolated from the core data struc- 
tures and functions of the database server. Improper 
modification of the core memory used by the database 
server is prevented by executing user-defined routines 
with a processor (e.g., a virtual processor) that has lim- 
ited privileges. The virtual processor is allowed full read 
and write (R/W) access either to a specified range of 
memory or to its own auxiliary memory segment de- 
pending on the particular implementation, but is limited 
to read-only access to the core database server mem- 
ory. As a result, the user is provided with enhanced flex- 
ibility while high degrees of reliability and performance 
are maintained for the database server. 

By enabling a routine to specify a class of virtual 
processor under which the routine is to be executed, da- 
tabase developers are provided with a flexible and pow- 
erful mechanism for isolating untrusted routines. A rou- 
tine may be run as trusted or untrusted simply by chang- 
ing a parameter to designate a virtual processor class 
with full R/W privileges or a "fenced" virtual processor, 
which has read-only privileges to a designated region of 
memory. 

In a configuration where the memory is logically par- 
titioned into segments, the memory segments occupy 
different portions of the same memory address space. 
As a result, the thread of execution for the user-defined 
routine can move between memory segments quickly 
and easily. Moreover, internal routines provided by the 
database server permit a fenced virtual processor to ac- 
cess resources present in the core memory segment 
while protecting the contents of the core memory seg- 
ment from being improperly modified. Isolation of un- 
trusted user-defined routines is thereby realised while 
high degrees of performance and scalability are main- 
tained for the database server. 

Embodiments of the present invention will now be 
described by way of example only, with reference to the, 
accompanying drawings in which: 

Fig 1 is a block diagram of a prior art relational da- 
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tabase. 

Fig 2 is a block diagram of a prior art extensible ob- 
ject-relational database management system. 

Figs 3A and 3B are examples of prior art database 
server, architectures. 

Fig 4 is a block diagram of a database server archi- 
tecture having multiple memory segments. 

Fig 5 is a block diagram of the Informix® Universal 
Server architecture. 

Fig 6 is a flowchart of executing routines in the In- 
formix® Universal Server architecture of FIG 5. 

Fig. 7 is a data diagram of a call back table that may 
be used in the Informix® Universal Server architecture 
of Fig. 5. 

Detailed Description 

The use of an extensible database management 
system (DBMS) to store persistent data provides sever- 
al advantages that are not available when a non-exten- 
sible DBMS is used as a data repository. The ability.to 
link routines for manipulating virtually any type of data 
directly to the database engine allows developers to tai- 
lor the DBMS to meet the specific needs of an enter- 
prise. Moreover, the ability to implement custom func- 
tions along with core DBMS functionality in a single-en- 
gine solution enhances the DBMS' performance, trans- 
action integrity, scalability and manageability, both for 
traditional and complex data types. 

Providing such a large degree of flexibility and ex- 
tensibility to developers potentially may cause prob- 
lems, however, depending on the DBMS architecture 
used. In the architecture of Fig. 3A, for example, a da- 
tabase server 300 receives database queries from cli- 
ents I, J and K (301-305) via communication links 307 
and conveys the database queries to threads Q, R or S 
as appropriate. Each client may communicate with a 
separate thread, as shown in Fig. 3A, or a single multi- 
threaded process may receive queries from two or more 
clients. In either case, the threads in turn make library 
calls to invoke predefined routines that perform the de- 
sired operations on the database. In Fig. 3A, all threads 
residing in the database server 300 execute their re- 
spective routines in the same memory address space — 
namely shared memory 302 - for which each thread has 
full R/W privileges. 

Ordinarily, allowing threads Q, R and S freely to 
read from and write to shared memory 302 would not 
cause problems with system operations because each 
of the underlying routines invoked by the threads would 
have been written by the same software vendor and 
thoroughly tested for correct operation and interopera- 
bility with every other routine linked to the database 
server 300. In some cases, however, a relatively unso- 
phisticated developer or end-user of a DBMS may write, 
and fail to properly debug, a data manipulation routine 
that is faulty -- i.e., execution of the routine causes it to 
modify the shared memory 302 of the database server 
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300 in an inappropriate way, potentially crashing the 
DBMS or corrupting the database or both. 

Fig. 3B depicts a solution for protecting the data- 
base server's shared memory from being damaged by 
s the execution of a faulty user-defined routine (UDR). In 
the architecture of Fig. 3B P database manipulation re- 
quests received from clients 301-305 are handled in dif- 
ferent manners depending on whether the underlying 
routines to which they correspond are regarded as 
10 "trusted" (e.g., UDRs that have been thoroughly tested 
to ensure that they do not improperly modify shared 
memory 302 or otherwise conflict with other routines) or 
"untrusted" (e.g., UDRs that have not been thoroughly 
tested). For those UDRs designated as belonging to a 

is trusted class, the calling thread executes the routine in 
shared memory 302 with full R/W privileges in the same 
manner as discussed above in connection with Fig. 3A. 

In the case of untrusted UDRs, however, the invok- 
ing thread (e.g., thread S) performs a remote procedure 

20 call (RPC) -- a programming mechanism that causes the 
thread to migrate from one memory address space to 
another memory address space while maintaining pro- 
gram context - to another server 310. Once the thread 
has migrated to server 310, the untrusted UDR is exe- 

25 cuted in memory 312 and the result is returned by pass- 
ing the thread back to DB server 300. Because memory 
312 in server 310 represents a memory address space 
that is separate and distinct from the shared memory 
302 in server 300, any routine executing on server 310 

30 is incapable of directly modifying shared memory 302. 
In effect, the RPC performed by thread S isolates the 
underlying execution thread from the database server 
300 thus protecting shared memory 302 from improper 
modification by the untrusted routine. 

35 Traversing between different memory address 
spaces is a relatively time-consuming activity, however. 
Each RPC to a different memory address space typically 
incurs a considerable amount of overhead time inmar- 
shalling and recovering arguments and results between 

40 the different servers. Moreover, the RPC-based archi- 
tecture relies on the proper operation of a communica- 
tions link between two or more different address spaces, 
each of which typically is associated with a separate 
computer system. Such inter-system communications 

^5 are considerably less reliable than intra-system commu- 
nications. The RPC-based isolation architecture conse- 
quently suffers from relatively poor performance and re- 
liability. 

These and other problems associated with the 
50 RPC-based isolation architecture are addressed by a 
database server architecture in which certain untrusted 
methods such as UDRs can be isolated from the core 
data structures and from trusted methods such as the 
core database engine routines. Isolation can be 
55 achieved by using either of at least two different models: 
a multi-process model and a single-process segment 
model. 

In the multi-process model, isolation can be accom- 
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plished in an architecture such as shown in Fig. 4 by 
maintaining multiple memory segments -- a main mem- 
ory segment 303 and an auxiliary memory segment 304, 
for example - within the same memory address space 

302. Segment 303 serves as the memory region in 
which trusted core database engine routines and core 
data structures are executed and stored. Memory seg- 
ment 304 serves as an auxiliary memory region re- 
served primarily for executing and storing routines and 
data other than those corresponding to core DBMS 
functions. 

A thread executing a trusted routine will remain in, 
and has full R/W privileges to, the main memory seg- 
ment 303. To execute an untrusted routine, however, the 
thread first migrates to the auxiliary memory segment 
304 to isolate the thread from the core memory segment 

303. A thread executing in the auxiliary memory seg- 
ment (e.g., thread S') has full R/W privileges to memory 
segment 304, but has read-only access to memory seg- 
ment 303. By constraining the areas of memory to which 
thread S 1 ' can write in executing ah untrusted routine, 
the core DBMS data structures and routines are protect- 
ed from being overwritten by a faulty UDR. Moreover, 
because trusted and untrusted routines are executed in 
the same memory address space (although in different 
memory segments), thread S' need not perform an RPC 
to perform an untrusted routine but rather can use a 
standard local procedure call, which generally is more 
reliable and requires an overhead time that is roughly 
an order of magnitude less than a RPC. As a result, iso- 
lation of untrusted routines can be achieved while main- 
taining relatively high levels of performance and reliabil- 
ity. , ^ . 

When the database server is implemented using a 

single process, isolation can be achieved within a core 
memory segment by modifying R/W privileges based on 
the nature of the routines being executed. In executing 
a trusted routine, the thread will have full R/W privileges 
to core memory in the ordinary fashion. Before execut- 
ing an untrusted routine, however, R/W permissions to 
a range of memory that corresponds to core database 
routines are switched to read-only for the thread that is 
executing the untrusted routine. Switching R/W privileg- 
es to a memory segment can be accomplished by either 
of two methods: (i) by invoking operating system-spe- 
cific routines to change R/W permissions on a specified 
range of memory, or (ii) by detaching the process in 
which the thread resides from the memory segment and 
then specifying different R/W access permissions upon 
reattaching the process to the memory segment. Under 
both methods, corruption of the database is prevented 
by prohibiting the untrusted routine from modifying a 
designated portion of memory. 

A detailed description of how the architecture of Fig. 
4 may be used in the Informix® Universal Server to ef- 
fectively isolate untrusted UDRs from trusted core data 
structures and DBMS routines is provided with refer- 
ence to Fig. 5. In the multi-processor environment 



shown, the IUS® uses multiple memory segments - 
core memory 402 and fenced memory 41 2. for example 
that occupy the same memory address space but 
which are logically partitioned from one another. The da- 

5 tabase server 400 is composed of one or more virtual 
processors (VPs) multi-threaded software entities that 
emulate hardware processors and which can accept 
and process multiple client requests concurrently. Each 
VP is an instance of a binary executable file running, for 

10 example, as a process in the UNIX operating system. 
The binary executable file includes the software compo- 
nents needed to form a ORDBMS plus the software 
components that provide the ability to interface with ex- 
tensions containing UDRs for handling arbitrary data 

is types. 

VPs come in a variety of classes, each class defin- 
ing certain characteristics that control the privileges 
available to, and the restrictions imposed upon, VPs 
within that class. Each routine that is linked to the data- 

20 base engine, whether a core database routine or a UDR, 
has an associated parameter, VPCLASS, that desig- 
nates the class of VP with which the routine is to be ex- 
ecuted, in general, a collection of functionally related 
routines is assigned to the same VP class. The VP- 

25 CLASS parameter may be changed at start-up to spec- 
ify a different class depending on the desired configura- 
tion of the database server. 

The database server may be composed of several 
different VPs, either from the same or different classes. 

30 The VPs are linked to a library of core database routines 
which are included as part of the IUS® system. The VPs 
also may be linked to one or more UDRs, for example, 
UDR-, and UDR 2 as shown in Fig. 5, which have been 
custom-designed to manage arbitrary data types spec- 

35 ified by a user of the IUS® system. Both the core data- 
base routines and the UDRs are implemented in the 
IUS® architecture using DataBlade® technology devel- 
oped by Informix®, Inc. A detailed description of DataB- 
lade® technology and how it may be used to create new 

40 UDRs is provided in the DataBlade® Developers Kit 
9.01 (Informix Order No. 82181), which is incorporated 
by reference. 

In the configuration shown in Fig. 5, the database 
server includes three different VPs 403, 405 and 409, 

45 each belonging to a different class. CPU VP 405 be- 
longs to the VP class "cpu," the class that runs routines 
most efficiently and which is the default VP class for 
most of the core database routines. CPU VP 405 re- 
ceives and handles all incoming database queries or 

so other client requests in the first instance. In processing 
a client request, the CPU VP may invoke other classes 
of VPs to perform specialized functions. For example, 
CPU VP 405 may invoke Extension VP 403 (VPCLASS 
= "ext") to service a blocking I/O request, thereby freeing 

ss the CPU VP to handle other client requests. 

All VP classes have static R/W privileges which are 
determined at the time of start-up of the database serv- 
er Unless otherwise specified, all VP classes by default 
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have full R/W privileges to core memory 402. An exten- 
sion VP may be designated, however, to run as a fenced 
VP by setting its VPCLASS to "fenced." Other VP class- 
es (e.g., "cpu," "aio," "tli") ordinarily do not support a 
fenced mode of operation. 

In Fig. 5 accordingly, Fenced VP 409 (i.e., an ex- 
tension VP having its VPCLASS set to "fenced") has full 
R/W privileges to fenced memory 412 but is limited to 
read-only access to core memory 402. By setting the 
VPCLASS parameter appropriately, the manner in 
which a routine is treated (e.g. , trusted versus untrusted) 
can be controlled. To run a UDR as a trusted routine, 
VPCLASS is set to "cpu" meaning that a CPU VP will 
execute the routine in the same manner as the core da- 
tabase engine routines. To run a UDR as a trusted rou- 
tine but in a memory segment other than the core mem- 
ory segment, VPCLASS is set to a VP class identifier 
other than ■cpu,'' for example, "ext." To run as an un- 
trusted routine in a memory segment other than the core 
memory segment, VPCLASS includes the identifier 
"fenced" meaning that the routine islo be executed by 
a VP that is "fenced off" from (i.e., unable to write to) the 
core memory segment. 

An explanation of how the database server switch- 
es between trusted and untrusted routines is provided 
with reference to the flowchart of Fig. 6. A client access- 
es the database server 400 by connecting, or "logging 
in," to the server (step 500) and issuing one or more 
requests (e.g., SQL queries) over the course of a login 
session. Upon first connecting to the database server 
400, each client is allocated a memory stack by the CPU 
VP 405 through a call to a core database routine, 
mt_alloc-stack () (step 502). The client's allocated 
stack region is used by one or more execution threads 
associated with that client in servicing the client's data- 
base requests issued during the login session. The 
stack allocation routine is also invoked when additional 
space is needed by an existing stack or to spawn a new 
worker thread for parallel processing of a client request. 

When a client sends a database query or other re- 
quest to the database server (step 504), CPU VP 405 
initiates processing of the query by determining which 
routines need to be executed to retrieve the specified 
information and present it in the appropriate format (step 
506). As part of the processing, the CPU VP 405 will 
also be likely to perform query optimization analysis and 
will initiate the execution of database manipulation op- 
erations. 

Eventually, the CPU VP typically will reach a point 
where one or more routines need to be executed to serv- 
ice the client's request. For each routine to be executed, 
CPU VP 405 examines the routine's VPCLASS param- 
eter to determine whether the routine is to be executed 
by a VP that has full R/W privileges to core memory 402 
or by Fenced VP 409, which has read-only privileges to 
core memory 402 (step 508). The bulk of the routines 
that are performed in servicing a client request typically 
are trusted core database routines which are executed 



in core memory 402 either by CPU VP 405 itself or by 
a unfenced VP of a class other than "cpu" (eg., Exten- 
sion VP 403). Some of the routines that are to be per- 
formed in servicing a client request, however, may be 
s untrusted UDRs which are executed by Fenced VP 409 
in fenced memory segment 412 to isolate the UDRs 
from the core database memory. 

If the VPCLASS parameter accordingly does not in- 
clude the word "fenced", the routine is treated as trusted. 
10 To do so, CPU VP 405 pushes parameters for the rou- 
tine onto the client's stack in core memory 402 (step 
510), and inserts into the main run queue 404 an entry 
for a thread to execute the routine (step 512). When the 
main run queue 404 next points to the routine's thread 
'5 entry, a VP from the class specified by the routine's VP- 
CLASS parameter picks up the thread and executes the 
requested routine in core memory 402 by popping the 
parameters off the client's stack and using them to per- 
form the instructions specified by the routine (step 514). 
20 in performing a trusted routine, the VP on which the rou- 
tine is running is allowed to write freely to and read from 
core memory 402 as needed. Upon completion, the rou- 
tine pushes any return parameters onto the client's 
stack and returns control to the appropriate location 
2S (516). 

If, however, the VPCLASS parameter includes the 
word "fenced", the thread running in the CPU VP 405 
migrates to Fenced VP 409 so that the routine (typically 
a UDR) can be executed in fenced memory segment 
30 412. CPU VP 405 initiates migration of the thread by 
calling a core database routine, mt_ priv_call ( ), which 
in turn calls mt_aUoc_stack () to allocat a memory 
stack (fenced stack 416) in fenced memory segment 
412 rather than in core allocated mt-prlv_csll ( ) per- 
35 forms a context switch by pushing parameters for the 
UDR onto the fenced stack 41 6 (step 520), and inserting 
a thread entry into a fenced run queue 414 (step 522), 
which is separately maintained for running untrusted 
routines. The Fenced VP 409 subsequently executes 
40 the untrusted UDR in fenced memory segment 412 
when the queued thread next runs (step 524). 

In executing a UDR, Fenced VP 409 may freely read 
from and write to fenced memory segment 412 but is 
prevented from writing^to the core memory segment 
4$ 402. Rather, Fenced VP 409 has read-only access to 
the core memory segment 402 to allow Fenced VP 409 
to read data in segment 402 as needed to perform the 
untrusted UDR. Fenced VP 409 is able to access re- 
sources residing in core memory 402 through internal 
so routines provided by the multi-threading (MT) interface, 
the server application program interface (SAPI) and the 
user-defined routine language manager (UDRLM). 
These internal routines detect whether the performance 
of a particular routine requires the thread to migrate be- 
ss tween memory segments. The SAPI interface library de- 
fines the supported routines that may be called by a 
UDR. A SAPI routine will detect upon entry that the cur- 
rent context is untrusted. If a routine executing in an un- 
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trusted context needs to modify core memory, it will 
switch to a trusted context via the mt_priv_call(), per- 
form the desired operations and switch back to the un- 
trusted context with another mt_priv_call(). Virtually 
any arbitrary number of switches between trusted and 
untrusted contexts may be performed in this manner By 
selectively switching contexts as needed, the thread of 
execution can move between memory segments and 
VPs in a manner that is transparent to the client proc- 
esses and to the UDRs. 

If during the execution of an untrusted routine, the 
Fenced VP executes an instruction that attempts to 
modify memory in the core memory segment while the 
thread is executing in the fenced memory segment, the 
Fenced VP is prevented from doing so. As a result, the 
core memory segment is protected from being improp- 
erly modified by a faulty UDR. Moreover, because the 
various operations involved with performing untrusted 
UDRs all take place within the same memory address 
space, only local calls are needed to switch between the 
memory segments thereby enhancing the speed and re- 
liability with which the routines may be performed. 

After the UDR has completed its execution in the 
fenced memory segment 412, a return from the 
mt _priv_callQ routine is performed so that the thread 
of execution migrates back to the CPU VP 405 in the 
core memory segment 402 (step 526). Because 
mt _priv_call() is merely another call on the thread's 
stack, returning from it returns the thread to the context 
from whence it came. As a result, the thread deallocates 
any resources it created in the fenced memory segment 
and commences execution in CPU VP 405. 

Although the database server memory in Fig. 5 is 
divided into two segments 402 and 404, an architecture 
having more memory segments could be implemented. 
The database server memory could be divided into three 
or more segments -- for example, one core segment and 
two or more fenced segments. Trusted routines can be 
executed in the core segment and UDRs can be exe- 
cuted in various fenced segments based on different 
classes to which the UDRs were assigned. For example, 
UDRs that had undergone considerable testing for prop- 
er operation and which had proven reliable could be as- 
signed to a first VP class while UDRs that had under- 
gone little or no testing could be assigned to one or more 
other VP classes. The proven-reliable UDRs belonging 
to the first VP class could be executed in one memory 
segment while the untested UDRs belonging to the oth- 
er classes could be executed in separate memory seg- 
ments to isolate them from the other UDRs. Isolating un- 
tested UDRs in this manner would prevent them not only 
from corrupting the core database server memory but 
also from crashing other UDRs. 

Moreover, the use of multiple fenced segments fa- 
cilitates easier fault identification. If multiple UDRs are 
executed in a single memory segment, determining 
which UDR is faulty can be difficult. By isolating UDRs 
to different memory segments, a faulty UDR can be 



identified from among several UDRs by determining 
which memory segment has been corrupted. 

Although each VP runs as a separate process on a 
UNIX-based platform, the collection of all active VPs 
could run on other platforms as a single process having 
multiple threads. The number and types of VPs that are 
present in the database server depends on the goals of 
the enterprise and is a matter of design choice for the 
system administrator. Each instance of a VP is a multi- 
threaded entity that can accept and process multiple cli- 
ent requests concurrently. For each class of VP, more 
than one instance of the VP may be active at the same 
time. For example, multiple instances of the CPU VP 
may be active at the same time, each servicing one or 
more client requests concurrently. 

Similarly, multiple instances of the fenced VP may 
exist, each executing one or more UDRs in parallel. A 
single instance of a fenced VP alternatively may process 
ail UDRs or each call to an untrusted routine may be 
serviced by a dedicated instance of the fenced VP Al- 
though the VPs in the architecture of Fig. 5 use static R/ 
W permissions (i.e., either full or fenced), different ar- 
chitectures are possible where the permissions for the 
VPs are switched dynamically based on whether or not 
a VP is executing a routine that is to be fenced from the 
core memory segment. Moreover, rather than spawning 
all VP instances at start-up, an instance of a VP could 
be spawned dynamically as needed, for example, in re- 
sponse to calling an untrusted UDR. 

in an alternative embodiment, a fenced VP execut- 
ing an untrusted UDR can perform "call backs" to core 
memory to access resources residing there while main- 
taining isolation of the untrusted UDR. The I US system 
maintains a table of allowable routine calls that modify 
resources residing in core memory. A fenced VP can 
invoke any of the routine calls specified in the call back 
table by indicating the corresponding ordinal position in 
the table for the desired routine. As shown in Fig. 7, for 
example, the fenced VP would designate position two 
(2) in the call back table 600 when the fenced VP wanted 
to invoke routine (y). When an unfenced VP, in order to 
perform the requested routine in core memory, next 
picked up the thread that was previously executing on 
the fenced VP. the unfenced VP would ensure that the 
memory address pointed to by the routine call was a le- 
gitimate and safe execution entry point in core memory 
by confirming that the requested routine was listed in 
call back table 600. If the requested routine was not list- 
ed in call back table 600, execution of the requested rou- 
tine would be blocked i.e., the unfenced VP would not 
execute the requested routine. In this manner, the call 
back table mechanism limits the routine calls that may 
be made by a fenced VP thereby preventing it from 
jumping to a potentially improper location in core mem- 
ory. 

The call back table may be implemented in at least 
two different manners. First, the call back table could 
contain a list of addresses of allowable routines. A UDR 
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seeking to call back to core memory would provide an 
entry point identifier to be used as an index to the call 
back table. An unfenced VP would perform the routine 
pointed to by the particular entry point identifier supplied 
by the UDR. Alternatively, the call back table could be s 
a list of legal execution addresses in core memory. Any 
entry point specified by a UDR would be checked 
against the execution addresses listed in the call back 
table to confirm the entry point's validity. 

The methods and mechanisms described here are 10 
not limited to any particular hardware or software con- 
figuration, but rather they may find applicability in any 
computing or processing environment in which data- 
base operations may be performed. 

The techniques described here may be implement- is 
ed in hardware or software, or a combination of the two. 
Preferably, the techniques are implemented in computer 
programs executing on programmable computers that 
each includes a processor, a storage medium readable 
by the processor (including volatile and non-volatile 20 
memory and/or storage elements), and suitable input 
and output devices. Program code is applied to data en- 
tered using an input device to perform the functions de- 
scribed and to generate output information. The output 
information is applied to one or more output devices. 2s 

Each program is preferably implemented in a high 
level procedural or object-oriented programming lan- 
guage to communicate with a computer system. How- 
ever, the programs can be implemented in assembly or 
machine language, if desired. In any case, the language 30 
may be a compiled or interpreted language. 

Each such computer program is preferably stored 
on a storage medium or device (e.g., CD-ROM, hard 
disk or magnetic diskette) that is readable by a general 
or special purpose programmable computer for config- 3S 
uring and operating the computer when the storage me- 
dium or device is read by the computer to perform the 
procedures described. The system also may be imple- 
mented as a computer-readable storage medium, con- 
figured with a computer program, where the storage me- 40 
dium so configured causes a computer to operate in a 
specific and predefined manner. \ 

Other embodiments are within the scope of the fol- 
lowing claims. 



Claims 



A method, performed by a database server, of per- 
forming or controlling routines for manipulating in- 
formation in a database, the method comprising: 
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determining whether a database manipulation 
routine is to be isolated from a specified range 
of memory; and ss 

selectively switching a memory access permis- 
sion for the database manipulation routine 
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based on the determination; and 

executing the database manipulation routine 
using the selectively switched memory access 
permission. 

!. The method of claim 1 in which determining whether 
a database manipulation routine is to be isolated 
comprises inspecting a parameter associated with 
the database manipulation routine. 

L The method of claim 2 further comprising, prior to 
the determination, setting the parameter to a value 
that specifies a class of processor for executing the 
database manipulation routine. 

. The method of claim 3 in which setting the param- 
eter comprises assigning the parameter a value that 
specifies a class of processor that is isolated from 
the specified range of memory. 

, The method of any preceding claim in which the se- 
lective switching comprises making a local proce- 
dure call. 

The method of any preceding claim in which the se- 
lective switching comprises setting the memory ac- 
cess permission for the database manipulation rou- 
tine to read-only for the specified range of memory 
if the database manipulation routine is determined 
to be a routine that is to be isolated from the spec- 
ified range of memory. 

The method of any preceding claim in which the se- 
lective switching comprises setting the memory ac- 
cess permission for the database manipulation rou- 
tine to read/write for the specified range of memory 
if the database manipulation routine is determined 
to be a routine that is not to be isolated from the 
specified range of memory. 

The method of any preceding claim in which the se- 
lective switching comprises migrating a thread of 
execution for the database ^manipulation, routine 
from a processor that has read/write permission to 
the specified range of memory to a processor that 
has read-only permission to the specified range of 
memory. 

The method of claim 8 in which the migrating com- 
prises maintaining the thread of execution within a 
same address space as the specified range, of 
memory. 

The method of any preceding claim in which the se- 
lective switch ing comprises switching from a trusted 
context in which a thread of execution for the data- 
base manipulation routine has read/write permis- 
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sion to the specified range of memory to an untrust- 
ed context in which the thread of execution has 
read-only permission to the specified range of 
memory. 

11. The method of claim 10 further comprising detect- 
ing that the thread of execution requires access to 
a resource residing in the specified range of mem- 
ory for which the thread of execution has read-only 
access to execute the database manipulation rou- 
tine. 

12. The method of claim 11 further comprising, upon de- 
tection that the thread of execution requires access 
to a resource residing in the specified range of 
memory, switching from the untrusted context to an- 
other trusted context in which the thread of execu- 
tion has read/write permission to the specified 
range of memory. 

13. The method of claim 12 further comprising switch- 
ing from the another trusted context to the untrusted 
context after the thread of execution for the data- 
base manipulation routine has completed access- 
ing the resource in the specified range of memory. 

1 4. The method of either of claims 1 2 or 1 3 further com- 
prising switching from the untrusted context to the 
trusted context after execution of the database ma- 
nipulation routine has completed. 

15. The method of any preceding claims in which the 
selective switching comprises performing an arbi- 
trary number of switches between a trusted context 
and an untrusted context. 

16. The method of any preceding claim in which'the ex- 
ecuting comprises remaining in the same address 
space as the specified range of memory while exe- 
cuting the database manipulation routine. 

17. The method of any preceding claim in which the ex- 
ecuting comprises performing the database manip- 
ulation routine with a processor that has read-only 
permission to the specified range of memory if the 
database manipulation routine is determined to be 
a routine that is to be isolated from the specified 
range of memory. 

1 8. The method of any preceding claim in which the ex- 
ecuting comprises performing the database manip- 
ulation routine with a processor.that has read/write 
permission to the specified range of memory if the 
database manipulation routine is determined to be 
a routine that is not to be isolated from the specific 
range of memory. 

19. The method of any preceding claim in which the ex- 



ecuting comprises performing the database manip- 
ulation routine in a memory segment that is logically 
partitioned from the specified range of memory if the 
database manipulation routine is determined to be 
5 a routine that is to be isolated from the specified 
range of memory. 

20. The method of any preceding claim in which the ex- 
ecuting comprises performing the database manip- 
10 ulation routine in the specified range of memory if 
the database manipulation routine is determined to 
be a routine that is not to be isolated from the spec- 
ified range of memory. 

is 21 . The method of any preceding claim in which the ex- 
ecuting comprises selectively allowing modification 
of resources residing in the specified range of mem- 
ory. 

20 22. The method of claim 21 in which the selective mod- 
ification is limited to one or more permissible exe- 
cution entry points in the specified range of memory. 

23. The method of claim 22 further comprising specify- 
25 ing the one or more permissible execution entry 

points in a call back table. 

24. The method as claimed in any preceding claim, fur- 
ther comprising concurrently executing a plurality of 

30 database manipulation routines in respective spec- 
ified ranges of the memory, each database manip- 
ulation routine having read-only access to all spec- 
ified ranges of memory other than its respective 
specified range of memory. 

35 

25. A database server for performing or controlling rou- 
tines for manipulating information in a database, the 
server comprising means for implementing a meth- 
od as claimed in any preceding claim. 

40 

26. A computer program product for performing or con- 
trolling routines for manipulating information in a da- 
tabase, the product comprising a computer reada- 
ble storage medium having embodied thereon com- 

45 puter program code for implementing a method as 
claimed in any of claims 1 to 24 or a database server 
as claimed in claim 25. 
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